Control server for supporting the charging of services

ABSTRACT

The invention concerns a Process and a control server for supporting the charging of services that are provided to a service user by a service server. A service request message from a terminal of the service user, requesting a service, is transmitted via a communication network to the service server. The service request message and one or more replies from the service server sent out on the service request message are routed via a control server. The control server carries out a procedure for the authentication of the service user and, using the result of the procedure, determines whether or not the charging of services requested by the service user is supported by the control server. The control server checks whether the reply from the service server contains an identification code, that classifies the requested service as chargeable. The control server prevents the provision of the requested service if the requested service is classified as chargeable and the control server has not determined that it supports the charging of services requested by the service user.

BACKGROUND OF THE INVENTION

[0001] The invention is based on a priority application No. DE 101 49160.3, which is hereby incorporated by reference.

[0002] The invention concerns a process and a control server forsupporting the charging of services that are supplied to a service userby a service server. In such a type of process a service request messagefor requesting a service is transmitted from a terminal of the serviceuser via a communication network to the service server.

[0003] There is the problem, particularly in the area of servicesoffered in the Internet, as to how the user of a service can be chargedfor the use of the service. The invention is based on the processdescribed below for charging services that are offered to a service uservia the Internet.

[0004] The so-called NET900 service employs a special dial-in node inthe Internet in order to charge the service user for the use ofinformation, to which he/she has access via the Internet. A service usercan access this service only by dialling in via this dial-in node, towhich a special telephone number is allocated. A call to this dial-innode is charged at a higher rate by the charging system of the telephonenetwork than that of a “normal” dial-in node.

[0005] The disadvantage of such a process is that it can only beemployed for an Internet access by means of ISDN (Integrated ServicesDigital Network) or modem.

[0006] Further solutions consist in installing special software moduleson the terminal of the service user and on the server of the serviceprovider, which facilitate payment of services by means of “electronicmoney”. The software module in the terminal can be loaded with“electronic money”, which is then used for payment of services.

[0007] These solutions have the drawback that they require the use ofspecial terminals and are only usable in the pre-paid area.

SUMMARY OF THE INVENTION

[0008] The object of the invention is now to facilitate a user-friendlycharging of services and in so doing keep the technical outlay as smallas possible.

[0009] Here a service can consist, for example, in the delivery ofinformation, data or software, but also in the sale of “concrete” goods.

[0010] The invention has the advantage that no special hardware orsoftware is required in the terminal area. It is thus particularlyeconomical and user-friendly.

[0011] Furthermore, the entire charging process is transparent for theservice user and service server. Existing charging systems can beintegrated in a simple manner. The technical outlay for the introductionof the invention into existing systems is thus also very small.

[0012] Advantageous developments of the invention are revealed in thesub-claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The invention is explained below by means of several exemplifyingembodiments and with the aid of the attached drawings.

[0014]FIG. 1 shows a block diagram of a system with several serviceusers, several service servers and two control servers according to theinvention.

[0015]FIG. 2 shows a functional representation of a control serveraccording to the invention, as in FIG. 1.

[0016]FIG. 3 shows a first flowchart of the communication between aterminal and a service server.

[0017]FIG. 4 shows a second flowchart of the communication between aterminal and a service server.

[0018]FIG. 5 shows a third flowchart of the communication between aterminal and a service server.

[0019]FIG. 6 shows a fourth flowchart of the communication between aterminal and a service server.

[0020]FIG. 1 shows two communication networks KN1 and KN2, three serviceusers SU1 to SU3, to which respective terminals TE1, TE2 and TE3 areassigned, two control servers CC1 and CC2, two charging systems BS1 andBS2, and four service servers SS1 to SS4.

[0021] The communication networks KN1 and KN2 involve the Internet, thatis to say a communication network that uses the IP protocol (Internetprotocol) as level 3 protocol. However, the communication networks KN1and KN2 can also be formed by different types of communication networks.

[0022] The communication network KN1 can be formed by a data network,for example, that itself is composed of different sub-networks. Suchsub-networks can be assigned to different network operators, forexample. These sub-networks can also be mobile radio networks in whichcommunication is based, for example, on the DECT, GSM, UMTS or Bluetoothstandards (DECT=Digital European Cordless Telecommunication, GSM=GlobalSystem for Mobile Communication, UMTS=Universal MobileTelecommunications System). Such sub-networks can also be formed bytelephone networks (data transmission by means of modem or ISDN). Thecommunication network KN1 can also consist entirely of a telephonenetwork.

[0023] The communication network KN2 can be formed by a data network,for example, that is based on a LAN (Local Area Network) protocol. Hereagain it is theoretically possible for the communication network KN2 tobe a telephone network.

[0024] Each of the service servers SS1 to SS4 are formed by one or moreinterconnected computers and by the software running on these computers.In each case, the service servers SS1 to SS4 provide the service usersSU1 to SU3 with one or more services. Here the services provided by theservice servers SS1 to SS4 can be of a different nature: for example thedelivery of information, data, programs, user-controlled filtering ofinformation or the sale of goods and services.

[0025] The service users SU1 to SU3 access the service servers SS1 toSS4 by means of the Internet. But it is also possible for the serviceusers to access the service servers SS1 to SS4 by means of the WAP(Wireless Application Protocol) or by means of a telephone terminal.Depending on the type of access, the service servers SS1 to SS4 thusfulfil the function of a WEB server, WAP server or IN (IntelligentNetwork), SCP (Service Control Point) and are accordingly technicallyequipped.

[0026] The terminals TE1 to TE3 are computers that are equipped withhardware and software components for communication via the communicationnetwork KN1. The terminals TE1 to TE3 therefore have a WEB browser viawhich they access the services provided by the service servers SS1 toSS4. It is also possible for the terminals TE1 to TE3 to be WAPterminals, UMTS terminals or just standard telephone terminals.

[0027] The control servers CC1 and CC2 are used to support the chargingof services supplied to the service users SU1 to SU3 by the serviceservers SS1 to SS4. In this case, on the one hand it is possible for thecontrol servers CC1 and CC2 to be assigned in each case to one specificgroup of service users. The control server CC1 Processes, for example,all service requests of the subscribers of a specific network operatoror Internet access operator. On the other hand, it is possible for thecontrol servers CC1 and CC2 to be assigned in each case to one or moreservice servers. The control server CC2 Processes, for example, allservice requests that are directed to services of a specific serviceoperator.

[0028] Here service servers and control servers can also constitutelogic function blocks that are implemented by applications programsrunning on the same hardware platform.

[0029] The charging systems BS1 and BS2 constitute systems by whichcharges for the use of the telecommunication services are billed to theservice users. In this case the charging systems BS1 and BS2 can reducea sum of money previously paid in (pre-paid) by the respective chargesincurred. There is an additional facility whereby the charges incurredin a specific time period are added and billed to the user at the end ofthe time period. The charging system BS1 can be, for example, the usualcharging system of a first telephone network operator and the chargingsystem BS2 that of a second telephone network operator. However, thecharging systems BS1 and BS2 can in each case also be the payment systemof a bank or credit institute.

[0030] To request a service, the terminal TE1 of the service user SU1sends a service request message to the service server SS1. This servicerequest message can, for example, consist of an HTTP/IP (HypertextTransport Protocol) message that is directed to the Internet address orthe WEB address of the service server SS1. However, this service requestmessage can also be a call request message of a telephone network, whichis addressed to an IN service provided by the service server SS1.

[0031] The service request message is transmitted to the service serverSS1 via the communication networks KN1 and KN2, and via the controlserver CC1. For this, the routing line in the communication networks KN1and KN2, or the addressing of the services provided by the serviceservers SS1 to SS4, is selected so that communication between theterminals TE1 to TE3 and the service server SS1 takes place via thecontrol server CC1. The service request message and one or more repliesof the service user SS1 sent out on the service request message aretherefore routed via the control server CC1.

[0032] On receipt of the service request message from the terminal TE1,the service server SS1 sends a reply to the terminal TE1. This reply canbe used for the provision of the service. However, the exchange ofseveral messages between the terminal TE1 and the service server SS1 canalso take place before the service is provided by the service serverSS1.

[0033] The control server CC1 checks whether the reply from the serviceserver SS1, or one of the replies from the service server SS1 containsan identification code that classifies the requested service aschargeable. This identification code can also consist of a symbol in thereply code or consist of a specific file name.

[0034] If this is the case, then the control server CC1 carries out aprocedure for authenticating the service user and determines from theresult whether or not the charging of services being requested by theservice user SU1 is supported by the control server. It is also possiblefor the service server to carry out this procedure independently of thereply from the service server. It is also possible for the serviceserver to carry out this procedure only once in the case of successiverequests from several services.

[0035] The procedure for authenticating the service user can alsocontain an authorisation procedure, pre-price information at the serviceuser or an explicit sales confirmation by the service user.

[0036] The control server CC1 thereupon prevents the provision of therequested service if the requested service is classified as chargeableand the control server has not determined that it supports the chargingof services that are being requested by the service user. Here thecontrol server CC1 can, for example, prevent the provision of therequested service by not forwarding replies from the service server SS1to the terminal TE1 or not forwarding messages from the terminal TE1 tothe service server SS1. The forwarding of an alternative content canreplace the non-forwarding action. Furthermore, the control server canalso send to the service server SS1 a special control message thatprevents the provision of the service. This can also be done by means ofa suitable manipulation of a message forwarded to the service serverSS1.

[0037] The detailed mode of operation of the control server CC1 is nowexplained with the aid of FIG. 2.

[0038]FIG. 2 shows the control server CC1 that communicates with theterminals TE1 to TE3 and with the service servers SS1 to SS4, and withthe charging system BS1.

[0039] The control server CC1 has one or more interconnected computersand a software platform running on these computers. Several applicationprograms run on this software platform. During the execution of theseapplication programs on the system platform of the control server CC1,formed by the hardware and software platform, the control server CC1 iscontrolled in such a way that the control server CC1 carries out thefunction of the control server CC1 as described below. The applicationprograms and the system platform needed to run the application programsthus form a control unit CONTR, which is configured in such a way thatit carries out the functions of the control server CC1 as describedbelow.

[0040] From a functional point of view, the control unit CONTR has threefunctions SH, AUT and LOG.

[0041] The AUT function carries out a procedure for authenticatingservice users. Using the result of the procedure, it determines whetheror not the charging of services that are requested by a service user issupported by the control server.

[0042] During the procedure for the authentication of service users, thecontrol server requests from the service user a user identificationcode, a password or an electronic signature, for example. Using thesedata, the function SH then checks which service user is requesting theservice.

[0043] During the procedure for the authentication the service user, thecontrol server CC1 can also check the authorisation by a chargingsystem. Only with positive authorisation does it determine that thecharging of services that are requested by the service user is supportedby the control server.

[0044] The authentication and authorisation of the service user can beimplemented by the control unit CONTR alone or with the support of thecharging system BS1.

[0045] Data for authenticating the service user can be stored locally inthe control server CC1. Furthermore, data that specify an authorisationof the charging system BS1 for certain charges or for a certain chargelevel can be stored locally in the control server CC1 for the serviceuser. A general authorisation for all charges incurred by a specificservice user is also possible. These data specify a type of “pre-paid”account, for example, which is reduced by each payment process, or forma type of credit frame for charges incurred by the service user. Usingthese data, the AUT function checks the authentication of the serviceuser and determines whether there is an authorisation for the respectivecharges in the context of the local, existing information. If the localframe is used up, then recourse is made to the charging system BS1.Especially in the case of small charges, this procedure has theadvantage that the charging outlay is very small and the charging costsare reasonable in comparison with the incurred charges.

[0046] A further possibility is that a server of this charging system isaccessed for checking the authorisation of the charging by the chargingsystem BS1. Using the transmitted data, this server determines whetherit approves a charging procedure in every individual case.

[0047] The function SH processes the messages received by the controlserver CC1, which come from the terminals TE1 to TE3 and from theservice servers SS1 to SS4. For each request for a service by one of theterminals TE1 to TE3, which is routed via the control server CC1, aprocess is started by the function SH, that controls the Processing ofthe respective service session by the control server CC1. Threeprocesses CH1 to CH3 are shown in FIG. 2 by way of example.

[0048] The process CH1 is started on receipt of a service requestmessage and forwards the service request message to that service serverto which it is directed. It checks whether the reply or one of thereplies of the service server to the service request message contains anidentification code, which classifies the requested service aschargeable.

[0049] The process CH1 further decides if and when the AUT function iscarried out for this service session: the determination as to whether ornot the charging of services being requested by the service user issupported by the control server CC1, can in this case be made at eachrequest for a service. However, it is also possible for thisdetermination to be valid for the request for two or more services.

[0050] With positive authorisation by another control server, forexample by the control server CC2, the process CH1 can dispense with theexecution of the AUT function and determine that the charging ofservices requested by the service user is also supported by the controlserver CC1.

[0051] The process CH1 further prevents the provision of the servicerequested by the service user if the requested service is classified aschargeable, and the AUT function has not determined that the controlserver CC1 supports the charging of services that are requested by thisservice user.

[0052] The LOG function stores data that provide information about thechargeable services requested by the individual service users. Such dataconcern, in particular, the level of these charges. The stored data aretransmitted to the charging system BS1 at specific intervals or directlyfor billing.

[0053] The detailed mode of operation of the control unit CONTR is alsoshown by the process sequences represented by way of example in FIGS. 3to 6.

[0054]FIG. 3 illustrates the mode of operation of the control unit CONTRfor the case where a non-chargeable service is requested by the terminalTE1.

[0055] A service request message REQ1, which contains the request for aspecific HTML page, for example, is transmitted by the terminal TE1 tothe control server CC1. The latter forwards the service request messageREQ1 unchanged to the service server SS1. The service server SS1transmits a reply ANS1, which contains the requested HTML page, forexample, to the control server CC1. The control server CC1 checks thereply ANS1 and determines that this is not classified as chargeable. Ittherefore forwards the reply ANS1 unchanged to the terminal TE1.

[0056]FIG. 4 shows the mode of operation of the control unit CONTR forthe case where a chargeable service is requested by the terminal TE1.

[0057] A service request message REQ2, which contains for example therequest for a specific HTML page, is transmitted by the terminal TE1 tothe control server CC1, which forwards the service request message REQ2unchanged to the service server SS1. The service server SS1 transmits areply ANS2(PT) to the control server CC1. The reply ANS2(PT) contains anidentification code PT that classifies the requested service aschargeable. Furthermore, the identification code PT contains additionaldata that specify the level of charges, or refer to a specific chargingsystem.

[0058] The control server CC1 checks the reply ANS2(PT) and determinesthat this is classified as chargeable.

[0059] Since the reply ANS2(PT) contains the identification code PT,which classifies the requested service as chargeable, the control serverCC1 carries out a procedure for the authentication of service users. Forthis it sends an HTML page LOGP to the terminal TE1. This page requeststhe service user SU1 to enter data for his authentication and to confirmthat he wishes to accept this chargeable service.

[0060] If the control server CC1 hereupon receives a user name UN, apassword PW and a confirmation PA, then it checks the authenticity ofthe service user SU1 and the authorisation for the charging. If theresult of the authentication and authorisation is positive, then itdetermines that the charging of services requested by the service userSU1 is supported by the control server CC1 and sends a message AD to theservice server SS1. On receipt of the message AD, the service serverdetermines an authorisation code PAC and a session cookie SCOOK andtransmits both to the control server CC1, which transmits these to theterminal TE1. Here the session cookie SCOOK contains a data record withservice user-specific data.

[0061] Advantageously, both the session cookie SCOOK and theauthorisation code PAC are provided with a specific expiry time. Thesession cookie SCOOK is given a parameter, for example, that instigatesthe erasure of the session cookie SCOOK from the memory of the terminalTE1. The authorisation code PAC is stored in the control server CC1along with the time instant at which it had been generated. Theauthorisation code then becomes invalid after about 1 minute.

[0062] The session cookie SCOOK can contain the following serviceuser-specific data, for example: language of the service user, currencyin which the service user wishes to pay, country in which the serviceuser is located, service user's operator, service user's chargingscheme, time instant at which the session cookie becomes invalid,identification code of the session, or IP address of the service.

[0063] These service user-specific data can of course also becommunicated between service server SS1 and terminal TE1 in another way.

[0064] It is also possible for the authorisation code PAC and thesession cookie SCOOK to be determined directly by the control server SS1and transmitted to the terminal TE1.

[0065] The session cookie SCOOK is stored by the terminal TE1. Theterminal TE1 is then induced to transmit a new service request messageREQ5 to the control server CC1. In this case the service request messageREQ5 contains the authorisation code PAC and the session cookie SCOOK.

[0066] The control server detects the session cookie SCOOK in theservice request message REQ5, determines an assigned session code SC andforwards the service request message REQ5 with the session code SCinstead of the session cookie SCOOK to the service server SS1. Theservice server SS1 now sends a reply ANS3 via the control server CC1 tothe terminal TE1. The reply ANS3 contains the requested chargeable WEBpage CONT, the authorisation code PAC and the session code SC.

[0067] It is advantageous to determine the session code SC along withthe authorisation code PAC and transport them to the terminal TE1 in thesession cookie SCOOK. However, the session code SC can also betransmitted to the terminal TE1 in another reply.

[0068] The control server CC1 now checks the reply ANS3 to see if thesession code SC and the authorisation code PAC are correct.

[0069] Using the session code SC, the control server CC1 detects thatthe service furnished by the reply ANS3 is chargeable. A reply whichresults in a non-chargeable service contains no session code (seeexemplifying embodiment in FIG. 3).

[0070] Using the check of the session code SC and the authorisation codePAC, the control server CC1 detects whether the control server CC1 hasdetermined that it supports the charging of services of the service userSU1. If the authorisation code and the session code is correct, thenthis is the case. This check can be made, for example, by means of adatabase in which the valid authorisation code and the assigned sessioncodes are stored.

[0071] If the control server CC1 detects that the service is classifiedas chargeable, and the control server has determined that it supportsthe charging of services of the service user SU1, then it forwards thereply ANS3 to the terminal TE1. In this case it removes the session codeSC and the authorisation code PAC from the reply ANS3. If this is notthe case, then it prevents the provision of the requested service by notforwarding the reply ANS3 of the service server SS1 to the terminal TE1.

[0072]FIG. 5 shows an alternative exemplifying embodiment to theexemplifying embodiment of FIG. 4 for the case where the terminal TE1accepts no cookies.

[0073] The exemplifying embodiment of FIG. 5 corresponds to the that ofFIG. 4, except for the following differences.

[0074] A service request message REQ3 from the terminal TE2 is forwardedto the service server SS1 via the control server CC1. No session cookieSCOOK is generated on pages of the service server SS1 and theauthorisation code PAC is transmitted without session cookie SCOOK tothe terminal TE2. However, it is possible for the session code SC to betransmitted to the terminal. The service request REQ5 contains nosession cookie SCOOK (some service user-specific data could thereforealso not be communicated between terminal TE2 and control server CC1).

[0075]FIG. 6 explains the mode of operation of the control unit CONTRfor the case where a chargeable service is requested by the terminal TE1and an authorisation code PAC has already been determined in an earlierservice request and transmitted to the terminal TE1. This is the case,for example, if, in connection with the exemplifying embodiment in FIG.4, a service of the service server SS1 is requested again by theterminal TE1.

[0076] A service request message REQ4, which, for example, contains therequest of a specific HTML page, is transmitted by the terminal TE1 tothe control server CC1, which forwards the service request message REQ2unchanged to the service server SS1. Here the service request messageREQ4 contains the session code SC that has been transmitted to theterminal during an earlier request for a chargeable service. The serviceserver SS1 transmits a reply ANS2(PT) to the control server CC1. Thereply ANS2(PT) contains the identification code PT that classifies therequested service as chargeable. The reply ANS2(PT) also contains thesession code SC.

[0077] The control server CC1 checks the reply ANS2(PT) and determinesthat this is classified as chargeable. It further determines that thereply ANS2(PT) contains a valid session code SC.

[0078] Since the reply ANS2(PT) contains the identification code PT,which classifies the requested service as chargeable, and the replycontains a valid session code SC, the control server CC1 does not carryout any procedure for the authentication of service users. Rather, itsends an HTML page CONFP to the terminal TE1. This page requests theservice user SU1 to confirm that it wishes to accept this chargeableservice. The transmission of the CONFP page could of course also bedispensed with.

[0079] The procedure for the authentication of service users istherefore not carried out if the reply from a service server to aservice request message contains a valid session code.

[0080] If the service user SU1 agrees with the request from thechargeable service, then the request message REQ5 with the authorisationcode PAC and the session code SC is sent to the control server CC1. Inthis case the sending of this message and the management of the sessioncode SC and the authorisation code PAC can be supported by the sessioncookie SCOOK, which is of course stored in the terminal TE1.

[0081] The request message REQ5 is forwarded by the control server CC1to the service server SS1, which then sends a reply ANS3 to the controlserver CC1. The reply ANS3 is handled by the control server CC1 like thereply ANS3 in FIG. 4.

1. A method for supporting the charging of services that are provided toa service user by a service server, wherein a service request messagefor requesting a service is transmitted by a terminal of the serviceuser via a communication network to the service server, wherein theservice request message and one or more replies of the service serversent out on the service request message are routed via a control server,the control server carries out a procedure for the authentication of theservice user and, using the result of the procedure, determines whetheror not the charging of services requested by the service user issupported by the control server, the control server checks whether thereply of the service server contains an identification code thatclassifies the requested service as chargeable, and the control serverprevents the provision of the requested service if the requested serviceis classified as chargeable and the control server has not determinedthat it supports the charging of services that are requested by theservice user.
 2. A method according to claim 1, wherein during theprocedure for the authentication of the service user, the control serveralso checks the authorisation by a charging system, and only in the caseof positive authorisation, determines that the charging of servicesrequested by the service user is supported by the control server.
 3. Amethod according to claim 2, wherein during the checking of theauthorisation by a charging system, the control server accesses a serverof the of the charging system.
 4. A method according to claim 1, whereinin the event of positive authorisation by another control server, thecontrol server determines that the charging of services requested by theservice user is supported by the control server.
 5. A method accordingto claim 1, wherein the determination as to whether or not the chargingof services requested by the service user is supported by the controlserver, is made at each request for a service.
 6. A method according toclaim 1, wherein the determination as to whether or not the charging ofservices requested by the service user is supported by the controlserver, is valid for the request for two or more services.
 7. A methodaccording to claim 1, wherein the service request message and one ormore of the replies of the service user sent out on the service requestmessage are routed via a control server assigned to the service operatorof the requested service.
 8. Control server for supporting the chargingof services that are provided to a service user by a service server,wherein the control server is provided with a control unit that isconfigured in such a way that it carries out a procedure for theauthentication of service users and, using the result of the procedure,determines whether or not the charging of services requested by aservice user is supported by the control server, that the control unitis further configured in such a way that it checks whether the reply ofa service server to a service request message of a service user containsan identification code that classifies the requested service aschargeable, and the control unit is further configured in such a waythat it prevents the provision of a service requested by a service user,if the requested service is classified as chargeable and said controlunit has not determined that the control server supports the charging ofservices requested by this service user.
 9. Control server according toclaim 1, wherein the control unit is further configured in such a waythat it prevents the provision of a service requested by a service userif the service user is not entitled to its use, or the service user doesnot authorise the payment required for use.
 10. Control server accordingto claim 1, wherein the control unit is further configured in such a waythat it forwards a service request message received by a terminal of aservice user to a service server.
 11. Control server according to claim1, wherein the control unit is further configured in such a way that itcarries out the procedure for the authentication of service users if thereply from a service server to a service request message of a serviceuser contains an identification code, that classifies the requestedservice as chargeable.
 12. Control server according to claim 1, whereinthe control unit is further configured in such a way that it determinesan authorisation code for a service user if it determines that thecharging of services requested by the service user is supported by thecontrol server, and that it transmits the authorisation code to theterminal of the service user.
 13. Control server according to claim 1,wherein the control unit is further configured in such a way that itrequests the service server to determine an authorisation code for aservice user, if it determines that the charging of services requestedby the service user is supported by the control server.
 14. Controlserver according to claim 1, wherein the control unit is furtherconfigured in such a way that it determines a session code for a serviceuser, if it determines that the charging of services requested by theservice user is supported by the control server, and that it transmitsthe session code to the terminal of the service user, and that thecontrol unit is further configured in such a way that it does not carryout the procedure for the authentication of service users if the replyfrom a service server to a service request message contains the sessioncode.
 15. Control server according to claim 1, wherein the control unitis further configured in such a way that it determines for a serviceuser a data record with service user-specific data, in particular acookie, and transmits it to the terminal of the service user. 16.Control server according to claim 1, wherein the control unit is furtherconfigured in such a way that it prevents the provision of a servicerequested by a service user, so that it does not forward a reply fromthe service server to a service request message to the terminal of theservice user.